Code Review — PR #858: Route permission requests through Oracle

Overall this is a clean, focused change that correctly enforces the Oracle pattern. The read/write split (prompt APIs as side-effects only, Oracle as the state source of truth) is well-reasoned and the ADR-001 update clearly documents the intent.

Strengths

• Correct Oracle pattern: Using currentSnapshot() before the prompt and forceRefresh() after is the right split. currentSnapshot() avoids a round-trip when the Oracle is warm; forceRefresh() ensures the return value reflects post-prompt reality.
• Discarding system API return values with _ clearly communicates they are now prompt side-effects only, not state sources.
• ADR-001 update is precise — the "write/prompt side effect" vs "state read" framing is a good canonical statement.
• Protocol updated atomically — no stale conformance lurking somewhere.

Issue 1: Outer Task in wizard pages is unstored — no cancellation on navigation

Both WizardAccessibilityPage.swift and WizardInputMonitoringPage.swift now wrap the entire flow (request call, polling setup, fallback) in an unattached Task { @MainActor in }. The task is not stored in any property, so it cannot be cancelled in onDisappear/view cleanup. The original fallback task had the same gap, but the request call itself was synchronous — here the whole flow, including the System Settings open, runs in the unstored task.

Suggestion: store the outer task handle alongside permissionPollingTask and cancel both on cleanup.

Issue 2: currentSnapshot() pre-check may use stale state

If the Oracle's cached snapshot is stale (e.g., user manually granted in System Settings between the last Oracle refresh and this call), currentSnapshot() returns "not granted" and the code falls through to IOHIDRequestAccess / AXIsProcessTrustedWithOptions. In practice the system dialog won't re-appear (those APIs silently return when already granted), and the subsequent forceRefresh() will catch it. No user-visible problem — but a short comment explaining why currentSnapshot() is preferred over forceRefresh() for the pre-check would make the intent clear to future readers.

Issue 3: Fallback timer starts later than before (minor)

The 1500ms fallback (WizardSleep.ms(1500)) now starts after requestAccessibilityPermission() returns, which itself ends with a forceRefresh(). In the original the 1500ms started immediately after the synchronous call. The Oracle refresh adds a small delay before the "open System Settings" fallback fires. Probably unnoticeable, just worth keeping in mind if the fallback UX ever feels sluggish.

Test coverage gap

The unrelated failures noted in the PR (CLIPackCRUDTests, HardViewSnapshotTests) are pre-existing. Oracle-relevant tests passed. One gap: the new "already granted before prompt" early-return path introduced by the beforePrompt check. A unit test mocking PermissionOracle with a pre-granted snapshot would lock in that behaviour and prevent future regressions.

Summary: The Oracle routing is correct and the approach is sound. The main item worth addressing before merge is the unstored outer Task — it means neither the requestAccessibilityPermission/requestInputMonitoringPermission call nor the System Settings fallback can be cancelled if the wizard page disappears mid-flow.